Skip to content

Add support for Hexagon architecture#4933

Open
androm3da wants to merge 8 commits into
bytecodealliance:mainfrom
androm3da:hexagon-upstream-v2
Open

Add support for Hexagon architecture#4933
androm3da wants to merge 8 commits into
bytecodealliance:mainfrom
androm3da:hexagon-upstream-v2

Conversation

@androm3da
Copy link
Copy Markdown

No description provided.

@androm3da androm3da force-pushed the hexagon-upstream-v2 branch 5 times, most recently from 0ccab07 to 4e6cd5a Compare May 7, 2026 19:41
androm3da added 8 commits May 29, 2026 00:09
Split V128 memory access (LOAD_V128/STORE_V128) into a separate
three-way guard independent of the scalar unaligned-access flag,
and add a target_supports_unaligned_simd field to AOTCompContext.
Add interpreter and AOT execution support for Qualcomm Hexagon DSP:
invokeNative trampoline, ELF relocation handler with PLT stubs,
wamrc --target=hexagon with auto -small-data, SIMD enablement, and
cross-compilation platform cmake.
- PLT_R28_TEMPLATE/PLT_JUMPR_R28: parse bits were 0b11 (DUPLEX) instead
  of 0b01 (end-of-packet), causing Hexagon CPU to misinterpret all PLT
  trampolines as duplex sub-instructions and crash on any external call.
- is_duplex(): condition was inverted — tested for bits==0 (ENDLOOP0)
  instead of bits==0xc000 (actual DUPLEX encoding).
- aot_llvm.c: replace strstr("-small-data") with a token-boundary-aware
  check so that feature strings containing "-small-data-limit=N" do not
  falsely suppress the mandatory "-small-data" disable flag.
…d/store

The WASM alignment hint is advisory per spec — the runtime must handle
any runtime address correctly regardless of the hint value.  Using
1<<align as the LLVM guaranteed-alignment on non-unaligned-simd targets
(RISC-V, MIPS, Xtensa, Thumb, Hexagon) tells the backend the address is
guaranteed to satisfy that alignment, which can generate aligned load/store
instructions that fault when the actual address does not meet the hint.

Always use LLVMSetAlignment(..., 1) for v128 load/store on all targets.
…d/store

Wire target_supports_unaligned_simd into simd_load/simd_store so the
flag is actually consulted: targets with native unaligned vector ops
(x86_64, aarch64) keep align=1, and others now receive 1<<align from
the WASM alignment hint as the surrounding comment documents.  Without
this the field was dead code and Hexagon AOT v128 loads still expanded
to byte-by-byte memub sequences.

Also drop ARC from the target_supports_unaligned_simd allowlist: ARC
is not in core/config.h's WASM_CPU_SUPPORTS_UNALIGNED_SIMD_ACCESS, so
listing it here made the AOT and runtime sides disagree.
- aot_reloc_hexagon.c: in R_HEX_B22_PCREL, only redirect through the
  PLT when the direct branch is out of range, and reject the redirect
  if reloc_addend != 0 (PLT entries are fixed trampolines and cannot
  carry a symbol+offset).  Previously the range check was applied even
  on the PLT path, making the PLT unable to rescue calls in modules
  whose code section exceeded ±8 MB; and a non-zero addend would have
  jumped into the middle of the next PLT trampoline.

- aot_llvm.c: tighten the Hexagon triple fallback detection from
  strstr(triple_norm, "hexagon") to a proper "hexagon"-prefix +
  component-boundary match so unrelated triples that happen to contain
  "hexagon" as a substring don't trigger -small-data injection.

- all.py: bump --start-fail-timeout to 30s under qemu_flag (default 2s
  is too short for qemu-hexagon user-mode trap-on-startup tests such as
  start.wast) and improve the comment around the Hexagon spec-test
  skip list explaining that the i32/i64 whole-suite skips are a
  workaround for the clang rotl/rotr miscompile.
@androm3da androm3da force-pushed the hexagon-upstream-v2 branch from 4e6cd5a to ac35bf8 Compare June 3, 2026 19:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant